在 dbt 自動化檢查系列文章中，我們已經介紹了 dbt_operator 和 git_diff_operator，這兩個模組主要用於識別異動的 models。今天要介紹的 bigquery_operator 則負責進一步檢查這些異動 models 的資料變化情況。

BigQuery Operator 核心功能

BigQuery Operator 設計了兩個核心功能來實現自動化檢查：

1. 產生檢查項目的查詢語句（Query）：根據不同的檢查需求，自動生成相應的 SQL 查詢
2. 執行查詢並整理結果：透過 BigQuery API 執行查詢並將結果標準化

基礎實現機制

使用 BigQuery API 執行查詢的程式碼如下：

from google.cloud import bigquery

client = bigquery.Client(project=project_id)
query = "SELECT * FROM table"
query_job = client.query(query)
result = query_job.result()

在 dbt model 中，我們根據不同的 materialized 類型採用不同的檢查策略。這種差異化的檢查方式能夠確保檢查的準確性和效率。以下會透過幾個檢查項目來說明

資料筆數異動檢查

檢查範圍劃分

1. 需要進行檢查的類型：
   • Table：實體表格
   • View：檢視表
2. 不需要檢查的類型：
   • UDF（table_function 和 function）：因為它們本質上是函數，不存在資料筆數的概念
   • Incremental 表：由於測試環境和正式環境的更新頻率不同，資料筆數的差異是預期中的正常現象

Table 的檢查方式

SELECT row_count
FROM `{dataset_name}`.__TABLES__
WHERE table_id = '{table_name}'

View 的檢查方式

SELECT COUNT(*) AS row_count
FROM `{dataset_name}.{table_name}`

為什麼我們要對 Table 和 View 採用不同的查詢方式呢？這是基於以下考量：

1. Table 的查詢優勢：
   • 使用 __TABLES__ 系統視圖可以一次性獲取整個 dataset 的所有表信息
   • 這種方式能顯著節省計算資源
   • 特別適合大規模數據表的檢查場景
2. View 的特殊處理：
   • View 是即時運算的結果，__TABLES__ 無法提供準確的資料筆數
   • 必須使用 COUNT(*) 進行實際計算才能得到準確結果
   • 雖然資源消耗較大，但是是獲取準確結果的唯一方式

在下一篇文章中，我們將繼續介紹另一個重要的檢查項目：孤兒物件。